@academey that's not strictly what we have in mind. Yes, remove devtools from the classpath that AOT considers to process the application, but also from the native image. This PR does the former, but not the latter. Would you be willing to amend it? There is some context in the linked issue.

@snicoll Thank you for the feedback. After investigating further, I understand the issue better now.

You're right. My current changes only exclude devtools from AOT processing but not from the native image itself. The issue is that while process-aot correctly excludes devtools, the native-maven-plugin still uses Maven's full classpath which includes devtools.

From my analysis, I see a few potential approaches

1. Configure exclusion in the native profile: We could add configuration to exclude devtools when the native profile is active, similar to how Gradle's developmentOnly configuration works.

2. Modify the parent POM's native profile: Add devtools exclusion to the native-maven-plugin configuration in spring-boot-starter-parent.

3. Use Maven's dependency scope: Leverage Maven's dependency management to ensure devtools doesn't appear in the runtime classpath for native builds.

Could you provide guidance on which approach would be most consistent with Spring Boot's design? I'm happy to implement the full solution once we agree on the direction.

For reference, I believe the issue occurs because native-maven-plugin uses the raw classpath (as mentioned in the AOT docs), and devtools remains in that classpath even though it's excluded from AOT processing.

I don't see the difference between 1 and 2. 2 is what I had in mind (at least trying) but it looks identical to 1.

@snicoll You're right approaches 1 and 2 are the same. I was overthinking it

I'll implement the solution by modifying the native profile in spring-boot-starter-parent to exclude devtools. This approach makes sense as it

• Centralizes the configuration
• Ensures consistent behavior across all projects using the parent POM
• Aligns with how we handle other native image configurations

I'll update the PR to include these changes. Thanks for the clarification

@snicoll I've updated the PR

The changes now include

1. AOT processing exclusion. Applied DEVTOOLS_EXCLUDE_FILTER in both ProcessAotMojo and ProcessTestAotMojo
2. Native image exclusion. Added exclusions for both spring-boot-devtools and spring-boot-docker-compose in the native-maven-plugin configuration within spring-boot-starter-parent

This ensures devtools is completely excluded from native images built with Maven, matching the Gradle behavior. The exclusions are applied automatically without requiring any user configuration.

Please let me know if this approach looks good or if you'd like any adjustments!

Thanks @academey. The added tests didn't really validate the code change here (in particular as Devtools doesn't run as part of AOT, #32517) but they are useful in case this changes in an unexpected way in the future.